From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 13 11:13:20 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§¶Ÿ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:20 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 13 11:13:20 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§¶Ÿ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:21 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:21 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Fri Jan 13 11:13:21 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:21 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Fri Jan 13 11:13:21 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 13 11:13:21 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§¶Ÿ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:21 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:21 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 13 11:13:21 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 13 11:13:21 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:21 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:21 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 13 11:13:21 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:21 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:21 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:21 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Jan 13 11:13:21 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:21 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:21 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Jan 13 11:13:21 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M4ÖŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M4ÖŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M4ÖŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 13 15:21:16 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M4ÚŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:16 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 13 15:21:16 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M4ÚŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:16 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:16 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Fri Jan 13 15:21:16 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:16 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Fri Jan 13 15:21:16 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 13 15:21:16 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M4ÚŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:16 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:16 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 13 15:21:16 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 13 15:21:16 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:16 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:16 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 13 15:21:16 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:16 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:16 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:16 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Jan 13 15:21:16 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:16 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:16 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Jan 13 15:21:16 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 13 16:00:49 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M4ÞŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:49 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 13 16:00:49 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M4ÞŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:49 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:49 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Fri Jan 13 16:00:49 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:49 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Fri Jan 13 16:00:49 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 13 16:00:49 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M4ÞŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:49 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:49 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 13 16:00:49 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 13 16:00:49 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:49 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:49 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 13 16:00:49 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:49 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:49 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:49 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Jan 13 16:00:49 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:49 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:49 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Jan 13 16:00:49 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 13 20:01:39 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M4⟠From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:39 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 13 20:01:39 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M4⟠From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:39 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:39 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Fri Jan 13 20:01:39 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:39 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Fri Jan 13 20:01:39 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 13 20:01:39 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M4⟠From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:39 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:39 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 13 20:01:39 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 13 20:01:39 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:39 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:40 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 13 20:01:40 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:40 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:40 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:40 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Jan 13 20:01:40 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:40 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:40 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Jan 13 20:01:40 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M4æŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M4æŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M4æŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M4êŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M4êŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M4êŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Jan 14 12:00:46 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 14 16:00:44 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M4îŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:44 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 14 16:00:44 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M4îŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:44 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M4îŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 14 20:00:42 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M4òŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:42 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 14 20:00:42 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M4òŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:42 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:42 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sat Jan 14 20:00:42 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:42 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sat Jan 14 20:00:42 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 14 20:00:42 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M4òŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:42 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:43 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 14 20:00:43 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 14 20:00:43 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:43 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:43 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 14 20:00:43 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:43 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:43 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:43 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Jan 14 20:00:43 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:43 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:43 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Jan 14 20:00:43 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 15 08:02:08 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M4öŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:08 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 15 08:02:08 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M4öŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:08 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:08 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sun Jan 15 08:02:08 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:08 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sun Jan 15 08:02:08 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 15 08:02:08 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M4öŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:08 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:08 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 15 08:02:08 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 15 08:02:08 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:08 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:08 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 15 08:02:08 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:08 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:08 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:08 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Jan 15 08:02:08 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:08 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:08 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Jan 15 08:02:08 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 15 12:00:52 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M5ÒŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:52 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 15 12:00:52 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M5ÒŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:52 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:52 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sun Jan 15 12:00:52 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:52 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sun Jan 15 12:00:52 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 15 12:00:52 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M5ÒŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:52 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:52 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 15 12:00:52 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 15 12:00:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 15 12:00:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:53 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:53 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:53 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Jan 15 12:00:53 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:53 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:53 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Jan 15 12:00:53 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M5ÖŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M5ÖŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M5ÖŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 15 20:00:44 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M5ÚŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:44 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 15 20:00:44 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M5ÚŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:44 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:44 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sun Jan 15 20:00:44 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:44 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sun Jan 15 20:00:44 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 15 20:00:44 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M5ÚŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:44 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:44 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 15 20:00:44 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 15 20:00:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 15 20:00:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:44 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Jan 15 20:00:44 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:44 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:44 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Jan 15 20:00:44 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 16 08:02:31 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M5ÞŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:31 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 16 08:02:32 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M5ÞŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:32 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:32 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Mon Jan 16 08:02:32 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:32 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Mon Jan 16 08:02:32 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 16 08:02:32 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M5ÞŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:32 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:32 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 16 08:02:32 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 16 08:02:32 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:32 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:32 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 16 08:02:32 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:32 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:32 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:32 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Jan 16 08:02:32 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:32 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:32 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Jan 16 08:02:32 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 16 12:00:48 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M5⟠From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:48 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 16 12:00:48 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M5⟠From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:48 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M5⟠From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M5æŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M5æŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M5æŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 16 20:00:44 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M5êŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:44 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 16 20:00:44 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M5êŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:44 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:44 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Mon Jan 16 20:00:44 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:44 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Mon Jan 16 20:00:44 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 16 20:00:44 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M5êŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:44 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:44 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 17 08:02:32 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M5îŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:34 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 17 08:02:34 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M5îŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:34 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:34 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Tue Jan 17 08:02:34 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:34 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Tue Jan 17 08:02:34 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 17 08:02:34 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M5îŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:34 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:34 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 17 08:02:34 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 17 08:02:34 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:34 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:34 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 17 08:02:34 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:34 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:34 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:34 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Jan 17 08:02:34 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:34 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:34 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Jan 17 08:02:34 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 17 12:01:02 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M5òŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:02 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 17 12:01:02 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M5òŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:02 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:02 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Tue Jan 17 12:01:02 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:02 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Tue Jan 17 12:01:02 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 17 12:01:02 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M5òŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:02 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:02 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 17 12:01:02 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 17 12:01:02 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:02 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:02 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 17 12:01:02 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:02 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:02 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:02 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Jan 17 12:01:02 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:02 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:02 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Jan 17 12:01:02 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 17 16:00:50 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M5öŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:50 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 17 16:00:50 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M5öŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:50 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:50 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Tue Jan 17 16:00:50 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:50 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Tue Jan 17 16:00:50 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 17 16:00:50 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M5öŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:50 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:50 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 17 16:00:50 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 17 16:00:50 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:50 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:51 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 17 16:00:51 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:51 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:51 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:51 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Jan 17 16:00:51 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:51 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:51 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Jan 17 16:00:51 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 17 20:00:52 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M6ÒŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:52 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 17 20:00:52 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M6ÒŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:52 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:52 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Tue Jan 17 20:00:52 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:52 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Tue Jan 17 20:00:52 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 17 20:00:52 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M6ÒŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:52 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:52 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 17 20:00:52 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 17 20:00:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 17 20:00:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:52 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Jan 17 20:00:52 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:52 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:52 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Jan 17 20:00:52 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Jan 18 08:04:17 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M6ÖŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:17 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Jan 18 08:04:17 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M6ÖŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:17 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:17 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Wed Jan 18 08:04:17 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:17 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Wed Jan 18 08:04:17 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Jan 18 08:04:17 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M6ÖŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:17 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:17 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Jan 18 08:04:17 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Jan 18 08:04:17 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:17 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:17 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Jan 18 08:04:17 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:17 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:17 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:17 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Jan 18 08:04:17 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:17 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:17 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Jan 18 08:04:17 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Jan 18 12:01:01 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M6ÚŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:04 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Jan 18 12:01:04 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M6ÚŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:04 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:04 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Wed Jan 18 12:01:04 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:04 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Wed Jan 18 12:01:05 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Jan 18 12:01:05 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M6ÚŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:05 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:05 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Jan 18 12:01:05 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Jan 18 12:01:05 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:05 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:05 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Jan 18 12:01:05 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:05 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:05 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:05 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Jan 18 12:01:05 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:05 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:05 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Jan 18 12:01:05 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Jan 18 16:01:29 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M6ÞŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:29 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Jan 18 16:01:29 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M6ÞŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:29 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:29 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Wed Jan 18 16:01:29 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:29 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Wed Jan 18 16:01:29 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Jan 18 16:01:29 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M6ÞŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:29 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:29 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Jan 18 16:01:29 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Jan 18 16:01:29 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:29 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:29 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Jan 18 16:01:29 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:29 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:29 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:29 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Jan 18 16:01:29 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:29 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:29 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Jan 18 16:01:30 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Jan 18 20:00:56 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M6⟠From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:56 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Jan 18 20:00:56 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M6⟠From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:56 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:56 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Wed Jan 18 20:00:56 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:56 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Wed Jan 18 20:00:56 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Jan 18 20:00:56 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M6⟠From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:56 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:56 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Jan 18 20:00:56 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Jan 18 20:00:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Jan 18 20:00:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:56 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Jan 18 20:00:56 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:56 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:56 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Jan 18 20:00:56 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Jan 19 08:04:38 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M6æŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:38 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Jan 19 08:04:39 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M6æŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:39 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:39 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Thu Jan 19 08:04:39 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:39 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Thu Jan 19 08:04:39 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Jan 19 08:04:39 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M6æŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:39 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:39 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Jan 19 08:04:39 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Jan 19 08:04:39 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:39 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:39 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Jan 19 08:04:39 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:39 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:39 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:39 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Jan 19 08:04:39 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:39 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:39 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Jan 19 08:04:39 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Jan 19 12:01:00 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M6êŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 12:01:00 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Jan 19 12:01:00 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M6êŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 12:01:00 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 12:01:01 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Thu Jan 19 12:01:01 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 12:01:01 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Thu Jan 19 12:01:01 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Jan 19 12:01:01 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M6êŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 12:01:01 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 12:01:01 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Jan 19 12:01:01 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Jan 19 12:01:01 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 12:01:01 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 12:01:01 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Jan 19 12:01:01 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 12:01:01 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 12:01:01 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 12:01:01 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Jan 19 12:01:01 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 12:01:01 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 12:01:01 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Jan 19 12:01:01 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Jan 19 16:02:55 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M6îŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:56 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Jan 19 16:02:56 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M6îŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:56 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:56 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Thu Jan 19 16:02:56 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:56 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Thu Jan 19 16:02:56 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Jan 19 16:02:57 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M6îŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:57 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:57 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Jan 19 16:02:57 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Jan 19 16:02:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Jan 19 16:02:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:57 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Jan 19 16:02:58 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:58 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:58 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Jan 19 16:02:58 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M6òŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M6òŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M6òŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 20 08:06:51 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M6öŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:54 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 20 08:06:54 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M6öŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:54 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:54 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Fri Jan 20 08:06:54 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:54 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Fri Jan 20 08:06:54 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 20 08:06:54 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M6öŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:54 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:55 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 20 08:06:55 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 20 08:06:55 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:55 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 20 08:06:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:56 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Jan 20 08:06:56 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:56 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:56 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Jan 20 08:06:56 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 20 12:02:03 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M7ÒŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:03 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 20 12:02:03 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M7ÒŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:03 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:03 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Fri Jan 20 12:02:03 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:03 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Fri Jan 20 12:02:03 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 20 12:02:03 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M7ÒŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:03 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:03 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 20 12:02:04 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 20 12:02:04 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:04 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:04 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 20 12:02:04 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:04 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:04 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:04 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Jan 20 12:02:04 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:04 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:04 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Jan 20 12:02:04 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 20 16:00:51 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M7ÖŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:53 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 20 16:00:53 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M7ÖŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:53 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:53 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Fri Jan 20 16:00:53 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:53 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Fri Jan 20 16:00:53 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M7ÖŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 20 20:00:47 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M7ÚŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:47 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 20 20:00:47 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M7ÚŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:47 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:47 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Fri Jan 20 20:00:47 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:47 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Fri Jan 20 20:00:47 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 20 20:00:47 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M7ÚŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:47 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:47 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 20 20:00:47 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 20 20:00:47 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:47 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:47 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 20 20:00:47 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:47 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:47 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:47 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Jan 20 20:00:48 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:48 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:48 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Jan 20 20:00:48 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 21 08:03:53 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M7ÞŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:53 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 21 08:03:53 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M7ÞŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:53 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:53 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sat Jan 21 08:03:53 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:53 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sat Jan 21 08:03:53 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 21 08:03:53 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M7ÞŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:53 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:53 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 21 08:03:53 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 21 08:03:53 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:53 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:53 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 21 08:03:53 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:53 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:53 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:53 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Jan 21 08:03:53 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:53 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:53 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Jan 21 08:03:53 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 21 12:01:02 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M7⟠From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:02 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 21 12:01:02 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M7⟠From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:02 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:02 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sat Jan 21 12:01:02 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:02 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sat Jan 21 12:01:02 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 21 12:01:02 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M7⟠From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:02 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:02 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 21 12:01:02 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 21 12:01:02 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:02 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:02 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 21 12:01:03 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:03 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:03 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:03 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Jan 21 12:01:03 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:03 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:03 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Jan 21 12:01:03 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 21 16:00:52 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M7æŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:52 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 21 16:00:52 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M7æŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:52 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:52 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sat Jan 21 16:00:52 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:52 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sat Jan 21 16:00:52 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 21 16:00:52 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M7æŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:52 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:52 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 21 16:00:52 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 21 16:00:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 21 16:00:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:52 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Jan 21 16:00:52 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:52 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:52 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Jan 21 16:00:52 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 21 20:00:50 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M7êŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:50 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 21 20:00:50 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M7êŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:50 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:50 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sat Jan 21 20:00:50 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:50 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sat Jan 21 20:00:50 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 21 20:00:50 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M7êŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 22 08:02:45 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M7îŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:45 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 22 08:02:45 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M7îŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:45 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:45 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sun Jan 22 08:02:45 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:45 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sun Jan 22 08:02:45 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 22 08:02:45 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M7îŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:45 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:45 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 22 08:02:45 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 22 08:02:45 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:45 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:45 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 22 08:02:45 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:45 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:45 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:45 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Jan 22 08:02:45 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:45 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:45 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Jan 22 08:02:45 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 22 12:00:52 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M7òŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:52 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 22 12:00:52 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M7òŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:52 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:52 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sun Jan 22 12:00:52 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:52 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sun Jan 22 12:00:52 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 22 12:00:52 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M7òŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:52 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:52 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 22 12:00:52 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 22 12:00:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 22 12:00:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:52 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Jan 22 12:00:52 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:52 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:52 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Jan 22 12:00:52 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 22 16:01:20 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M7öŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:20 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 22 16:01:21 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M7öŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:21 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:21 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sun Jan 22 16:01:21 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:21 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sun Jan 22 16:01:21 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 22 16:01:21 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M7öŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:21 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:21 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 22 16:01:21 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 22 16:01:21 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:21 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:21 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 22 16:01:21 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:21 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:21 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:21 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Jan 22 16:01:21 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:21 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:21 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Jan 22 16:01:21 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 22 20:01:15 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M8ÒŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:15 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 22 20:01:15 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M8ÒŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:15 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:15 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sun Jan 22 20:01:15 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:15 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sun Jan 22 20:01:15 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 22 20:01:16 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M8ÒŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:16 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:16 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 22 20:01:16 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 22 20:01:16 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:16 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:16 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 22 20:01:16 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:16 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:16 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:16 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Jan 22 20:01:16 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:16 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:16 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Jan 22 20:01:16 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 23 08:02:41 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M8ÖŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:42 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 23 08:02:42 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M8ÖŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:42 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:42 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Mon Jan 23 08:02:42 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:42 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Mon Jan 23 08:02:42 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 23 08:02:42 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M8ÖŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:42 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:42 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 23 08:02:42 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 23 08:02:42 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:42 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:42 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 23 08:02:42 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:42 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:42 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:42 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Jan 23 08:02:42 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:42 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:42 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Jan 23 08:02:42 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 23 12:00:57 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M8ÚŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:57 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 23 12:00:57 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M8ÚŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:57 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:57 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Mon Jan 23 12:00:57 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:57 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Mon Jan 23 12:00:57 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 23 12:00:57 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M8ÚŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:57 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:57 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 23 12:00:57 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 23 12:00:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 23 12:00:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:57 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Jan 23 12:00:57 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:57 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:57 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Jan 23 12:00:57 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 23 16:01:46 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M8ÞŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:46 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 23 16:01:46 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M8ÞŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:46 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:47 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Mon Jan 23 16:01:47 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:47 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Mon Jan 23 16:01:47 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 23 16:01:47 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M8ÞŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:47 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:47 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 23 16:01:47 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 23 16:01:47 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:47 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:47 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 23 16:01:47 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:47 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:47 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:47 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Jan 23 16:01:47 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:47 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:48 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Jan 23 16:01:48 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M8⟠From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M8⟠From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M8⟠From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 24 08:03:11 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M8æŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:11 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 24 08:03:11 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M8æŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:11 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:11 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Tue Jan 24 08:03:11 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:11 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Tue Jan 24 08:03:11 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 24 08:03:12 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M8æŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:12 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:12 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 24 08:03:12 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 24 08:03:12 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:12 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:13 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 24 08:03:13 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:13 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:13 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:13 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Jan 24 08:03:13 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:13 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:13 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Jan 24 08:03:13 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 24 12:02:55 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M8êŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:55 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 24 12:02:55 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M8êŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:55 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:56 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Tue Jan 24 12:02:56 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:56 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Tue Jan 24 12:02:56 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 24 12:02:56 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M8êŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:56 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:56 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 24 12:02:56 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 24 12:02:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 24 12:02:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:57 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Jan 24 12:02:57 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:57 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:58 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Jan 24 12:02:58 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 24 16:01:22 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M8îŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:22 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 24 16:01:22 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M8îŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:22 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:22 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Tue Jan 24 16:01:22 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:23 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Tue Jan 24 16:01:23 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 24 16:01:23 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M8îŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:23 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:23 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 24 16:01:23 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 24 16:01:23 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:23 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:23 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 24 16:01:23 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:23 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:23 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:23 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Jan 24 16:01:23 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:23 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:23 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Jan 24 16:01:23 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 24 20:01:55 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M8òŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:55 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 24 20:01:55 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M8òŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:55 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:55 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Tue Jan 24 20:01:55 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:55 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Tue Jan 24 20:01:56 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 24 20:01:56 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M8òŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:56 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:56 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 24 20:01:56 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 24 20:01:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 24 20:01:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:56 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Jan 24 20:01:56 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:56 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:56 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Jan 24 20:01:56 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Jan 25 08:02:02 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M8öŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:02 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Jan 25 08:02:02 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M8öŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:02 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:02 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Wed Jan 25 08:02:02 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:02 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Wed Jan 25 08:02:02 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Jan 25 08:02:02 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M8öŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:02 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:02 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Jan 25 08:02:02 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Jan 25 08:02:02 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:02 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:02 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Jan 25 08:02:02 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:02 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:03 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:03 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Jan 25 08:02:03 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:03 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:03 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Jan 25 08:02:03 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Jan 25 12:01:02 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M9ÒŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:02 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Jan 25 12:01:02 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M9ÒŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:02 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:02 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Wed Jan 25 12:01:02 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:02 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Wed Jan 25 12:01:02 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Jan 25 12:01:02 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M9ÒŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:02 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:02 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Jan 25 12:01:02 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Jan 25 12:01:02 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:02 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:02 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Jan 25 12:01:02 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:02 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:02 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:02 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Jan 25 12:01:02 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:02 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:02 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Jan 25 12:01:02 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Jan 25 16:01:01 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M9ÖŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:01 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Jan 25 16:01:01 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M9ÖŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:01 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:01 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Wed Jan 25 16:01:01 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:01 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Wed Jan 25 16:01:01 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Jan 25 16:01:01 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M9ÖŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:01 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:01 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Jan 25 16:01:01 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Jan 25 16:01:01 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:01 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:01 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Jan 25 16:01:01 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:01 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:01 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:01 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Jan 25 16:01:01 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:01 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:01 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Jan 25 16:01:01 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Jan 25 20:00:54 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M9ÚŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:54 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Jan 25 20:00:54 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M9ÚŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:54 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:54 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Wed Jan 25 20:00:54 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:54 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Wed Jan 25 20:00:54 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Jan 25 20:00:54 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M9ÚŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:54 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:54 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Jan 25 20:00:54 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Jan 25 20:00:54 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:54 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:54 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Jan 25 20:00:54 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:54 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:54 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:54 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Jan 25 20:00:54 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:54 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:54 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Jan 25 20:00:54 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Jan 26 08:05:43 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M9ÞŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:43 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Jan 26 08:05:43 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M9ÞŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:43 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:43 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Thu Jan 26 08:05:43 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:43 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Thu Jan 26 08:05:43 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Jan 26 08:05:44 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M9ÞŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:44 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:44 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Jan 26 08:05:44 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Jan 26 08:05:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Jan 26 08:05:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:44 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Jan 26 08:05:44 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:45 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:45 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Jan 26 08:05:45 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Jan 26 12:01:06 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M9⟠From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:06 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Jan 26 12:01:06 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M9⟠From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:06 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:06 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Thu Jan 26 12:01:06 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:06 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Thu Jan 26 12:01:06 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Jan 26 12:01:06 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M9⟠From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:06 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:06 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Jan 26 12:01:06 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Jan 26 12:01:06 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:06 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:06 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Jan 26 12:01:06 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:06 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:06 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:06 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Jan 26 12:01:06 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:06 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:06 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Jan 26 12:01:06 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Jan 26 16:00:53 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M9æŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:53 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Jan 26 16:00:53 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M9æŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:53 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:53 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Thu Jan 26 16:00:53 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:53 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Thu Jan 26 16:00:53 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Jan 26 16:00:53 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M9æŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:53 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:53 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Jan 26 16:00:54 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Jan 26 16:00:54 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:54 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:54 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Jan 26 16:00:54 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:54 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:54 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:54 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Jan 26 16:00:54 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:54 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:54 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Jan 26 16:00:54 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M9êŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M9êŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M9êŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 27 08:06:40 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M9îŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:41 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 27 08:06:41 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M9îŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:41 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:41 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Fri Jan 27 08:06:41 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:41 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Fri Jan 27 08:06:41 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 27 08:06:41 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M9îŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:41 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:41 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 27 08:06:41 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 27 08:06:42 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:42 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:42 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 27 08:06:42 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:42 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:42 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:42 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Jan 27 08:06:42 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:42 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:42 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Jan 27 08:06:42 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 27 12:02:10 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M9òŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:10 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 27 12:02:10 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M9òŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:10 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:10 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Fri Jan 27 12:02:10 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:10 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Fri Jan 27 12:02:11 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 27 12:02:11 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M9òŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:11 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:11 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 27 12:02:11 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 27 12:02:11 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:11 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:11 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 27 12:02:11 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:11 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:11 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:11 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Jan 27 12:02:11 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:11 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:11 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Jan 27 12:02:11 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 27 16:01:07 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M9öŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:07 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 27 16:01:07 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M9öŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:07 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:07 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Fri Jan 27 16:01:07 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:07 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Fri Jan 27 16:01:07 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 27 16:01:07 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M9öŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:07 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:07 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 27 16:01:07 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 27 16:01:07 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:07 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:07 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 27 16:01:07 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:07 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:07 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:07 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Jan 27 16:01:07 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:07 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:07 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Jan 27 16:01:07 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 27 20:00:55 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M:ÒŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:55 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 27 20:00:55 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M:ÒŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:55 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:55 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Fri Jan 27 20:00:55 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:55 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Fri Jan 27 20:00:55 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Jan 27 20:00:55 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M:ÒŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:56 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:56 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 27 20:00:56 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 27 20:00:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Jan 27 20:00:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:56 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Jan 27 20:00:56 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:56 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:56 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Jan 27 20:00:56 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 28 08:05:38 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M:ÖŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:38 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 28 08:05:38 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M:ÖŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:38 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:38 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sat Jan 28 08:05:38 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:38 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sat Jan 28 08:05:38 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 28 08:05:39 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M:ÖŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:39 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:39 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 28 08:05:39 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 28 08:05:39 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:39 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:39 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 28 08:05:39 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:39 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:39 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:41 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Jan 28 08:05:41 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:41 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:41 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Jan 28 08:05:41 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 28 12:01:54 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M:ÚŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:54 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 28 12:01:54 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M:ÚŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:55 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:55 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sat Jan 28 12:01:55 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:55 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sat Jan 28 12:01:55 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 28 12:01:55 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M:ÚŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:55 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:55 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 28 12:01:55 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 28 12:01:55 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:55 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:55 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 28 12:01:55 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:55 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:55 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:55 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Jan 28 12:01:55 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:55 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:55 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Jan 28 12:01:55 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 28 16:00:56 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M:ÞŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:56 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 28 16:00:56 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M:ÞŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:56 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:57 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sat Jan 28 16:00:57 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:57 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sat Jan 28 16:00:57 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 28 16:00:57 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M:ÞŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:57 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:57 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 28 16:00:57 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 28 16:00:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 28 16:00:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:57 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Jan 28 16:00:57 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:57 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:57 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Jan 28 16:00:57 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 28 20:00:56 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M:⟠From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:56 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 28 20:00:57 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M:⟠From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:57 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:57 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sat Jan 28 20:00:57 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:57 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sat Jan 28 20:00:57 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Jan 28 20:00:57 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M:⟠From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:57 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:57 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 28 20:00:57 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 28 20:00:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Jan 28 20:00:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:57 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Jan 28 20:00:57 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:57 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:57 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Jan 28 20:00:57 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 29 08:07:33 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M:æŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:33 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 29 08:07:33 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M:æŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:33 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:33 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sun Jan 29 08:07:33 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:33 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sun Jan 29 08:07:33 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 29 08:07:33 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M:æŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:33 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:33 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 29 08:07:33 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 29 08:07:33 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:33 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:33 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 29 08:07:33 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:33 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:33 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:33 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Jan 29 08:07:34 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:34 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:34 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Jan 29 08:07:34 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 29 12:01:00 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M:êŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:00 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 29 12:01:00 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M:êŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:00 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:00 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sun Jan 29 12:01:00 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:00 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sun Jan 29 12:01:00 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 29 12:01:00 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M:êŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:00 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:00 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 29 12:01:00 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 29 12:01:00 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:00 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:00 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 29 12:01:01 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:01 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:01 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:01 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Jan 29 12:01:01 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:01 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:01 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Jan 29 12:01:01 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M:îŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M:îŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M:îŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 29 20:00:55 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M:òŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:55 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 29 20:00:55 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M:òŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:55 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:55 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sun Jan 29 20:00:55 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:55 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sun Jan 29 20:00:55 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Jan 29 20:00:55 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M:òŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:55 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:55 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 29 20:00:55 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 29 20:00:55 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:55 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:55 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Jan 29 20:00:55 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:55 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:56 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Jan 29 20:00:56 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:56 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:56 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Jan 29 20:00:56 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 30 08:08:45 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M:öŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 08:08:46 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 30 08:08:47 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M:öŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 08:08:47 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 08:08:47 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Mon Jan 30 08:08:47 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 08:08:47 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Mon Jan 30 08:08:47 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 30 08:08:48 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M:öŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 08:08:48 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 08:08:48 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 30 08:08:48 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 30 08:08:48 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 08:08:48 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 08:08:48 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 30 08:08:48 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 08:08:48 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 08:08:48 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 08:08:48 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Jan 30 08:08:48 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 08:08:49 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 08:08:49 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Jan 30 08:08:49 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 30 12:03:54 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M;ÒŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:55 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 30 12:03:55 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M;ÒŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:55 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:55 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Mon Jan 30 12:03:55 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:55 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Mon Jan 30 12:03:55 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 30 12:03:56 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M;ÒŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:56 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:56 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 30 12:03:56 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 30 12:03:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 30 12:03:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:56 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Jan 30 12:03:56 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:56 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:56 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Jan 30 12:03:56 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 30 16:04:11 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M;ÖŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:11 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 30 16:04:12 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M;ÖŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:12 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:12 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Mon Jan 30 16:04:12 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:12 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Mon Jan 30 16:04:12 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 30 16:04:12 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M;ÖŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:12 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:12 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 30 16:04:12 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 30 16:04:12 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:12 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:12 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 30 16:04:12 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:12 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:12 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:12 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Jan 30 16:04:12 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:12 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:12 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Jan 30 16:04:13 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 30 20:02:13 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M;ÚŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:13 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 30 20:02:14 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M;ÚŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:14 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:14 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Mon Jan 30 20:02:14 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:14 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Mon Jan 30 20:02:14 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Jan 30 20:02:14 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M;ÚŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:14 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:14 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 30 20:02:14 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 30 20:02:14 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:14 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:14 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Jan 30 20:02:14 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:14 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:14 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:14 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Jan 30 20:02:14 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:14 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:14 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Jan 30 20:02:14 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 31 08:07:51 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M;ÞŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:51 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 31 08:07:51 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M;ÞŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:51 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:51 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Tue Jan 31 08:07:51 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:51 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Tue Jan 31 08:07:52 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 31 08:07:52 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M;ÞŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:52 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:52 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 31 08:07:52 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 31 08:07:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 31 08:07:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:52 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:52 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Jan 31 08:07:52 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:52 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:52 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Jan 31 08:07:52 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 31 12:04:17 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M;⟠From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:17 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 31 12:04:17 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M;⟠From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:17 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:17 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Tue Jan 31 12:04:17 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:17 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Tue Jan 31 12:04:17 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 31 12:04:17 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M;⟠From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:17 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:17 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 31 12:04:17 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 31 12:04:17 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:17 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:17 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 31 12:04:17 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:17 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:17 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:17 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Jan 31 12:04:18 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:18 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:18 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Jan 31 12:04:18 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 31 16:02:19 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M;æŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:19 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 31 16:02:19 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M;æŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:19 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:19 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Tue Jan 31 16:02:19 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:19 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Tue Jan 31 16:02:20 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 31 16:02:20 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M;æŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:20 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:20 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 31 16:02:20 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 31 16:02:20 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:20 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:20 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 31 16:02:20 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:20 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:20 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:20 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Jan 31 16:02:20 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:20 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:20 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Jan 31 16:02:20 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 31 20:01:09 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M;êŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:09 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 31 20:01:09 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M;êŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:09 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:09 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Tue Jan 31 20:01:09 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:09 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Tue Jan 31 20:01:09 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Jan 31 20:01:09 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M;êŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:09 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:09 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 31 20:01:09 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 31 20:01:09 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:09 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:09 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Jan 31 20:01:09 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:09 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:09 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:09 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Jan 31 20:01:09 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:09 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:09 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Jan 31 20:01:09 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 1 08:09:37 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M;îŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:37 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 1 08:09:38 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M;îŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:38 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:38 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Wed Feb 1 08:09:38 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:38 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Wed Feb 1 08:09:38 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 1 08:09:39 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M;îŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:40 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:40 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 1 08:09:40 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 1 08:09:40 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:40 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:40 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 1 08:09:40 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:40 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:40 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:41 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Feb 1 08:09:41 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:41 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:41 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Feb 1 08:09:41 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 1 12:02:43 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M;òŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:43 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 1 12:02:43 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M;òŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:44 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:44 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Wed Feb 1 12:02:44 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:44 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Wed Feb 1 12:02:44 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 1 12:02:44 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M;òŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:44 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:44 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 1 12:02:44 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 1 12:02:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 1 12:02:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:44 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Feb 1 12:02:44 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:44 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:44 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Feb 1 12:02:44 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 1 16:01:07 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M;öŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:07 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 1 16:01:07 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M;öŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:07 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:07 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Wed Feb 1 16:01:07 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:07 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Wed Feb 1 16:01:07 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 1 16:01:07 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M;öŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:07 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:07 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 1 16:01:07 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 1 16:01:07 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:07 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:07 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 1 16:01:07 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:08 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:08 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:08 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Feb 1 16:01:08 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:08 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:08 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Feb 1 16:01:08 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 1 20:01:00 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M<ÒŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:00 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 1 20:01:00 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M<ÒŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:00 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:00 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Wed Feb 1 20:01:00 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:00 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Wed Feb 1 20:01:00 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 1 20:01:00 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M<ÒŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:01 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:01 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 1 20:01:01 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 1 20:01:01 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:01 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:01 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 1 20:01:01 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:01 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:01 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:01 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Feb 1 20:01:01 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:01 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:01 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Feb 1 20:01:01 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Feb 2 08:12:29 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M<ÖŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 08:12:30 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Feb 2 08:12:31 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M<ÖŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 08:12:31 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 08:12:31 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Thu Feb 2 08:12:31 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 08:12:31 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Thu Feb 2 08:12:31 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Feb 2 08:12:33 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M<ÖŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 08:12:33 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 08:12:33 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Feb 2 08:12:33 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Feb 2 08:12:34 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 08:12:34 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 08:12:34 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Feb 2 08:12:34 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 08:12:34 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 08:12:34 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 08:12:34 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Feb 2 08:12:34 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 08:12:34 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 08:12:34 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Feb 2 08:12:35 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Feb 2 12:02:48 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M<ÚŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:48 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Feb 2 12:02:48 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M<ÚŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:48 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:48 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Thu Feb 2 12:02:48 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:49 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Thu Feb 2 12:02:49 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Feb 2 12:02:50 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M<ÚŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:50 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:50 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Feb 2 12:02:50 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Feb 2 12:02:50 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:50 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:50 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Feb 2 12:02:50 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:50 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:50 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:50 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Feb 2 12:02:50 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:50 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:50 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Feb 2 12:02:50 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Feb 2 16:01:11 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M<ÞŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:11 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Feb 2 16:01:11 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M<ÞŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:11 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:11 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Thu Feb 2 16:01:11 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:11 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Thu Feb 2 16:01:11 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Feb 2 16:01:12 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M<ÞŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:12 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:12 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Feb 2 16:01:12 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Feb 2 16:01:12 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:12 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:12 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Feb 2 16:01:12 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:12 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:12 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:12 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Feb 2 16:01:12 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:12 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:12 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Feb 2 16:01:12 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Feb 2 20:01:01 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M<⟠From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:01 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Feb 2 20:01:02 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M<⟠From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:02 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:02 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Thu Feb 2 20:01:02 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:02 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Thu Feb 2 20:01:02 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Feb 2 20:01:02 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M<⟠From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:02 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:02 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Feb 2 20:01:02 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Feb 2 20:01:02 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:02 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:02 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Feb 2 20:01:02 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:02 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:02 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:02 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Feb 2 20:01:02 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:02 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:02 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Feb 2 20:01:02 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Feb 3 08:12:09 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M<æŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 08:12:11 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Feb 3 08:12:11 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M<æŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 08:12:12 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 08:12:12 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Fri Feb 3 08:12:12 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 08:12:12 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Fri Feb 3 08:12:12 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Feb 3 08:12:13 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M<æŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 08:12:13 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 08:12:13 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Feb 3 08:12:13 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Feb 3 08:12:13 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 08:12:13 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 08:12:13 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Feb 3 08:12:13 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 08:12:13 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 08:12:13 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 08:12:14 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Feb 3 08:12:14 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 08:12:14 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 08:12:14 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Feb 3 08:12:14 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Feb 3 12:02:40 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M<êŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:40 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Feb 3 12:02:40 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M<êŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:40 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:40 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Fri Feb 3 12:02:40 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:40 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Fri Feb 3 12:02:40 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Feb 3 12:02:41 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M<êŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:41 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:41 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Feb 3 12:02:41 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Feb 3 12:02:41 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:41 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:41 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Feb 3 12:02:41 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:41 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:41 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:41 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Feb 3 12:02:41 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:41 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:41 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Feb 3 12:02:41 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Feb 3 16:01:02 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M<îŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:02 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Feb 3 16:01:02 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M<îŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:02 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:02 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Fri Feb 3 16:01:02 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:02 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Fri Feb 3 16:01:02 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Feb 3 16:01:02 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M<îŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:02 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:02 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Feb 3 16:01:02 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Feb 3 16:01:02 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:02 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:02 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Feb 3 16:01:03 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:03 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:03 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:03 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Feb 3 16:01:03 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:04 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:04 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Feb 3 16:01:04 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Feb 3 20:01:08 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M<òŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:08 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Feb 3 20:01:08 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M<òŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:08 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:08 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Fri Feb 3 20:01:08 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:08 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Fri Feb 3 20:01:08 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Feb 3 20:01:08 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M<òŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:08 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:08 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Feb 3 20:01:08 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Feb 3 20:01:08 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:08 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:08 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Feb 3 20:01:08 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:08 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:08 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:08 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Feb 3 20:01:08 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:08 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:08 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Feb 3 20:01:08 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Feb 4 08:07:53 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M<öŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 08:07:54 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Feb 4 08:07:54 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M<öŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 08:07:54 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 08:07:55 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sat Feb 4 08:07:55 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 08:07:55 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sat Feb 4 08:07:55 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Feb 4 08:07:56 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M<öŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 08:07:56 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 08:07:56 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Feb 4 08:07:56 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Feb 4 08:07:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 08:07:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 08:07:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Feb 4 08:07:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 08:07:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 08:07:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 08:07:56 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Feb 4 08:07:57 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 08:07:57 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 08:07:57 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Feb 4 08:07:57 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Feb 4 12:02:43 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M=ÒŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:43 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Feb 4 12:02:43 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M=ÒŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:43 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:43 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sat Feb 4 12:02:43 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:43 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sat Feb 4 12:02:43 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Feb 4 12:02:43 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M=ÒŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:44 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:44 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Feb 4 12:02:44 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Feb 4 12:02:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Feb 4 12:02:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:44 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Feb 4 12:02:44 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:44 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:44 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Feb 4 12:02:44 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Feb 4 16:01:13 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M=ÖŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:13 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Feb 4 16:01:13 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M=ÖŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:13 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:13 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sat Feb 4 16:01:13 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:13 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sat Feb 4 16:01:13 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Feb 4 16:01:13 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M=ÖŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:13 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:13 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Feb 4 16:01:13 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Feb 4 16:01:13 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:13 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:13 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Feb 4 16:01:13 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:13 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:13 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:13 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Feb 4 16:01:13 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:13 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:13 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Feb 4 16:01:13 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Feb 4 20:01:02 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M=ÚŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:03 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Feb 4 20:01:03 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M=ÚŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:03 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:03 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sat Feb 4 20:01:03 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:03 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sat Feb 4 20:01:03 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Feb 4 20:01:03 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M=ÚŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:03 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:03 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Feb 4 20:01:03 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Feb 4 20:01:03 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:03 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:03 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Feb 4 20:01:03 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:03 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:03 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:03 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Feb 4 20:01:03 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:03 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:03 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Feb 4 20:01:03 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Feb 5 08:07:56 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M=ÞŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:56 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Feb 5 08:07:56 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M=ÞŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:56 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:56 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sun Feb 5 08:07:56 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:56 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sun Feb 5 08:07:56 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Feb 5 08:07:56 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M=ÞŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:56 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:56 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Feb 5 08:07:56 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Feb 5 08:07:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Feb 5 08:07:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:57 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Feb 5 08:07:57 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:57 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:57 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Feb 5 08:07:57 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Feb 5 12:02:42 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M=⟠From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:43 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Feb 5 12:02:43 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M=⟠From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:43 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:43 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sun Feb 5 12:02:43 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:44 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sun Feb 5 12:02:44 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Feb 5 12:02:44 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M=⟠From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:44 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:44 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Feb 5 12:02:44 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Feb 5 12:02:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Feb 5 12:02:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:44 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Feb 5 12:02:44 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:44 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:44 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Feb 5 12:02:44 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Feb 5 16:01:07 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M=æŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:07 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Feb 5 16:01:07 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M=æŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:07 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:07 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sun Feb 5 16:01:07 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:07 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sun Feb 5 16:01:07 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Feb 5 16:01:07 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M=æŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:07 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:07 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Feb 5 16:01:07 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Feb 5 16:01:07 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:07 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:07 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Feb 5 16:01:07 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:07 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:07 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:07 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Feb 5 16:01:07 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:07 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:07 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Feb 5 16:01:07 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Feb 5 20:00:59 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M=êŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:59 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Feb 5 20:00:59 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M=êŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:59 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:59 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sun Feb 5 20:00:59 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:59 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sun Feb 5 20:00:59 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Feb 5 20:01:00 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M=êŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 20:01:00 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 20:01:00 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Feb 5 20:01:00 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Feb 5 20:01:00 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 20:01:00 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 20:01:00 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Feb 5 20:01:00 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 20:01:00 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 20:01:00 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 20:01:00 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Feb 5 20:01:00 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 20:01:00 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 20:01:00 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Feb 5 20:01:00 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Feb 6 08:14:54 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M=îŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 08:14:59 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Feb 6 08:15:01 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M=îŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 08:15:01 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 08:15:01 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Mon Feb 6 08:15:01 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 08:15:02 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Mon Feb 6 08:15:03 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Feb 6 08:15:05 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M=îŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 08:15:05 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 08:15:05 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Feb 6 08:15:06 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Feb 6 08:15:06 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 08:15:06 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 08:15:06 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Feb 6 08:15:08 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 08:15:08 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 08:15:08 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 08:15:09 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Feb 6 08:15:09 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 08:15:09 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 08:15:09 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Feb 6 08:15:09 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Feb 6 12:02:41 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M=òŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:41 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Feb 6 12:02:43 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M=òŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:43 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:43 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Mon Feb 6 12:02:43 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:43 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Mon Feb 6 12:02:43 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Feb 6 12:02:43 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M=òŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:43 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:43 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Feb 6 12:02:43 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Feb 6 12:02:43 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:43 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Feb 6 12:02:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:44 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:44 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Feb 6 12:02:44 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:44 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:44 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Feb 6 12:02:44 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Feb 6 16:01:05 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·M=öŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:05 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Feb 6 16:01:05 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·M=öŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:05 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:05 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Mon Feb 6 16:01:05 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:05 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Mon Feb 6 16:01:05 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Feb 6 16:01:06 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·M=öŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:06 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:06 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Feb 6 16:01:08 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Feb 6 16:01:08 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:08 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:08 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Feb 6 16:01:08 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:08 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:08 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:08 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Feb 6 16:01:08 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:08 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:08 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Feb 6 16:01:08 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Feb 6 20:01:00 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MtÒŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:00 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Feb 6 20:01:01 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MtÒŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:01 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:01 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Mon Feb 6 20:01:01 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:01 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Mon Feb 6 20:01:01 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Feb 6 20:01:01 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MtÒŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:01 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:01 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Feb 6 20:01:01 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Feb 6 20:01:01 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:01 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:01 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Feb 6 20:01:01 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:01 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:01 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:01 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Feb 6 20:01:01 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:01 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:01 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Feb 6 20:01:01 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Feb 7 08:23:08 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MtÖŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 08:23:10 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Feb 7 08:23:16 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MtÖŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 08:23:16 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 08:23:16 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Tue Feb 7 08:23:17 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 08:23:17 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Tue Feb 7 08:23:17 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Feb 7 08:23:23 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MtÖŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 08:23:23 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 08:23:24 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Feb 7 08:23:24 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Feb 7 08:23:24 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 08:23:24 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 08:23:24 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Feb 7 08:23:24 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 08:23:24 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 08:23:25 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 08:23:25 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Feb 7 08:23:25 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 08:23:25 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 08:23:25 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Feb 7 08:23:26 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Feb 7 12:03:17 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MtÚŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:17 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Feb 7 12:03:18 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MtÚŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:18 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:18 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Tue Feb 7 12:03:18 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:18 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Tue Feb 7 12:03:18 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Feb 7 12:03:18 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MtÚŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:18 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:19 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Feb 7 12:03:19 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Feb 7 12:03:19 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:19 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:19 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Feb 7 12:03:19 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:19 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:19 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:19 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Feb 7 12:03:19 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:19 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:19 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Feb 7 12:03:19 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Feb 7 16:01:09 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MtÞŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:09 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Feb 7 16:01:09 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MtÞŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:09 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:09 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Tue Feb 7 16:01:09 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:09 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Tue Feb 7 16:01:09 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Feb 7 16:01:09 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MtÞŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:09 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:09 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Feb 7 16:01:09 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Feb 7 16:01:09 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:09 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:09 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Feb 7 16:01:09 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:09 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:09 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:09 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Feb 7 16:01:09 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:09 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:09 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Feb 7 16:01:09 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Feb 7 20:01:05 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·Mt⟠From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:05 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Feb 7 20:01:05 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·Mt⟠From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:05 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:06 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Tue Feb 7 20:01:06 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:06 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Tue Feb 7 20:01:06 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Feb 7 20:01:06 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·Mt⟠From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:06 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:06 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Feb 7 20:01:06 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Feb 7 20:01:06 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:06 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:06 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Feb 7 20:01:06 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:06 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:06 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:06 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Feb 7 20:01:06 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:06 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:06 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Feb 7 20:01:06 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 8 08:22:22 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MtæŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 08:22:26 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 8 08:22:30 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MtæŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 08:22:30 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 08:22:30 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Wed Feb 8 08:22:30 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 08:22:30 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Wed Feb 8 08:22:31 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 8 08:22:32 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MtæŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 08:22:32 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 08:22:32 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 8 08:22:32 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 8 08:22:32 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 08:22:33 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 08:22:33 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 8 08:22:33 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 08:22:33 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 08:22:33 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 08:22:33 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Feb 8 08:22:33 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 08:22:33 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 08:22:34 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Feb 8 08:22:34 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 8 12:03:22 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MtêŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 12:03:22 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 8 12:03:22 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MtêŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 12:03:22 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 12:03:22 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Wed Feb 8 12:03:22 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 12:03:22 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Wed Feb 8 12:03:22 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 8 12:03:23 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MtêŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 12:03:23 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 12:03:23 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 8 12:03:23 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 8 12:03:23 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 12:03:23 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 12:03:23 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 8 12:03:23 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 12:03:23 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 12:03:23 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 12:03:23 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Feb 8 12:03:23 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 12:03:23 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 12:03:23 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Feb 8 12:03:23 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 8 16:01:14 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MtîŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:14 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 8 16:01:14 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MtîŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:14 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:15 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Wed Feb 8 16:01:15 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:15 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Wed Feb 8 16:01:15 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 8 16:01:15 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MtîŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:15 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:15 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 8 16:01:15 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 8 16:01:15 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:15 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:15 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 8 16:01:15 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:15 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:15 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:15 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Feb 8 16:01:15 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:15 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:15 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Feb 8 16:01:15 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 8 20:01:05 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MtòŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:05 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 8 20:01:05 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MtòŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:05 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:05 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Wed Feb 8 20:01:05 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:05 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Wed Feb 8 20:01:05 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 8 20:01:05 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MtòŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:05 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:05 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 8 20:01:05 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 8 20:01:05 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:05 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:05 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 8 20:01:05 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:05 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:05 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:05 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Feb 8 20:01:05 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:05 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:05 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Feb 8 20:01:05 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Feb 9 08:09:13 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MtöŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 08:09:14 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Feb 9 08:09:14 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MtöŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 08:09:15 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 08:09:15 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Thu Feb 9 08:09:15 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 08:09:15 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Thu Feb 9 08:09:15 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Feb 9 08:09:16 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MtöŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 08:09:16 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 08:09:17 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Feb 9 08:09:18 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Feb 9 08:09:18 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 08:09:18 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 08:09:18 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Feb 9 08:09:18 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 08:09:18 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 08:09:18 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 08:09:18 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Feb 9 08:09:18 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 08:09:19 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 08:09:19 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Feb 9 08:09:19 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Feb 9 12:03:11 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MuÒŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:13 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Feb 9 12:03:14 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MuÒŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:14 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:14 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Thu Feb 9 12:03:14 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:14 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Thu Feb 9 12:03:14 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Feb 9 12:03:15 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MuÒŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:15 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:15 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Feb 9 12:03:15 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Feb 9 12:03:15 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:15 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:15 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Feb 9 12:03:15 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:15 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:15 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:15 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Feb 9 12:03:15 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:15 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:15 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Feb 9 12:03:16 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Feb 9 16:01:16 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MuÖŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:16 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Feb 9 16:01:16 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MuÖŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:16 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:16 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Thu Feb 9 16:01:16 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:16 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Thu Feb 9 16:01:16 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Feb 9 16:01:16 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MuÖŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:16 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:16 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Feb 9 16:01:16 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Feb 9 16:01:16 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:16 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:16 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Feb 9 16:01:16 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:16 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:16 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:16 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Feb 9 16:01:16 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:16 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:16 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Feb 9 16:01:16 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Feb 9 20:01:10 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MuÚŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:10 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Feb 9 20:01:10 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MuÚŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:10 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:10 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Thu Feb 9 20:01:10 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:10 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Thu Feb 9 20:01:10 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Feb 9 20:01:10 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MuÚŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:10 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:10 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Feb 9 20:01:10 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Feb 9 20:01:10 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:10 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:10 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Feb 9 20:01:10 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:10 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:10 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:10 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Feb 9 20:01:10 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:10 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:10 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Feb 9 20:01:10 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Feb 10 08:19:47 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MuÞŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 08:19:48 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Feb 10 08:19:49 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MuÞŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 08:19:49 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 08:19:52 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Fri Feb 10 08:19:52 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 08:19:52 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Fri Feb 10 08:19:52 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Feb 10 08:19:54 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MuÞŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 08:19:54 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 08:19:54 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Feb 10 08:19:54 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Feb 10 08:19:54 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 08:19:54 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 08:19:55 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Feb 10 08:19:55 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 08:19:55 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 08:19:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 08:19:57 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Feb 10 08:19:57 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 08:19:57 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 08:19:57 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Feb 10 08:19:57 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Feb 10 12:03:38 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·Mu⟠From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:38 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Feb 10 12:03:38 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·Mu⟠From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:38 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:38 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Fri Feb 10 12:03:38 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:38 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Fri Feb 10 12:03:38 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Feb 10 12:03:39 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·Mu⟠From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:39 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:39 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Feb 10 12:03:39 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Feb 10 12:03:39 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:39 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:39 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Feb 10 12:03:39 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:39 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:39 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:39 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Feb 10 12:03:40 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:40 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:40 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Feb 10 12:03:40 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Feb 10 16:01:09 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MuæŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:09 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Feb 10 16:01:09 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MuæŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:09 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:09 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Fri Feb 10 16:01:09 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:09 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Fri Feb 10 16:01:09 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Feb 10 16:01:10 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MuæŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:10 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:11 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Feb 10 16:01:11 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Feb 10 16:01:11 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:11 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:11 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Feb 10 16:01:11 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:11 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:11 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:11 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Feb 10 16:01:11 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:11 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:11 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Feb 10 16:01:11 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Feb 10 20:01:13 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MuêŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:13 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Feb 10 20:01:13 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MuêŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:13 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:13 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Fri Feb 10 20:01:13 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:13 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Fri Feb 10 20:01:13 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Feb 10 20:01:13 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MuêŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:13 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:13 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Feb 10 20:01:13 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Feb 10 20:01:13 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:13 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:13 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Feb 10 20:01:13 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:13 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:13 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:13 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Feb 10 20:01:13 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:13 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:13 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Feb 10 20:01:13 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Feb 11 08:12:49 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MuîŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:49 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Feb 11 08:12:49 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MuîŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:50 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:50 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sat Feb 11 08:12:50 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:50 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sat Feb 11 08:12:50 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Feb 11 08:12:50 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MuîŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:50 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:50 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Feb 11 08:12:50 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Feb 11 08:12:50 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:51 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:51 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Feb 11 08:12:51 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:51 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:51 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:51 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Feb 11 08:12:51 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:51 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:51 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Feb 11 08:12:51 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Feb 11 12:02:38 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MuòŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:38 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Feb 11 12:02:38 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MuòŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:38 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:39 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sat Feb 11 12:02:39 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:39 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sat Feb 11 12:02:39 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Feb 11 12:02:39 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MuòŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:39 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:39 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Feb 11 12:02:39 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Feb 11 12:02:39 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:39 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:39 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Feb 11 12:02:39 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:40 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:40 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:40 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Feb 11 12:02:40 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:40 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:40 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Feb 11 12:02:40 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Feb 11 16:01:04 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MuöŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:04 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Feb 11 16:01:04 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MuöŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:04 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:04 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sat Feb 11 16:01:04 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:04 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sat Feb 11 16:01:04 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Feb 11 16:01:04 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MuöŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:04 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:04 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Feb 11 16:01:04 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Feb 11 16:01:04 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:04 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:04 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Feb 11 16:01:04 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:04 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:04 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:04 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Feb 11 16:01:07 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:07 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:07 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Feb 11 16:01:07 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MvÒŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MvÒŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MvÒŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Feb 12 08:09:17 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MvÖŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 08:09:17 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Feb 12 08:09:18 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MvÖŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 08:09:18 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 08:09:18 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sun Feb 12 08:09:18 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 08:09:18 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sun Feb 12 08:09:18 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Feb 12 08:09:20 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MvÖŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 08:09:20 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 08:09:20 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Feb 12 08:09:20 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Feb 12 08:09:20 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 08:09:20 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 08:09:20 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Feb 12 08:09:20 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 08:09:20 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 08:09:20 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 08:09:21 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Feb 12 08:09:21 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 08:09:21 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 08:09:21 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Feb 12 08:09:21 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Feb 12 12:02:47 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MvÚŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:47 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Feb 12 12:02:47 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MvÚŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:47 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:47 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sun Feb 12 12:02:47 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:47 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sun Feb 12 12:02:48 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Feb 12 12:02:48 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MvÚŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:48 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:48 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Feb 12 12:02:48 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Feb 12 12:02:48 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:48 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:48 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Feb 12 12:02:48 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:48 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:48 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:48 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Feb 12 12:02:48 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:48 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:48 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Feb 12 12:02:48 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Feb 12 16:01:10 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MvÞŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:10 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Feb 12 16:01:10 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MvÞŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:10 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:10 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sun Feb 12 16:01:10 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:10 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sun Feb 12 16:01:10 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Feb 12 16:01:10 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MvÞŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:10 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:10 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Feb 12 16:01:10 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Feb 12 16:01:10 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:10 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:10 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Feb 12 16:01:10 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:10 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:10 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:10 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Feb 12 16:01:10 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:11 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:11 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Feb 12 16:01:11 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Feb 12 20:01:03 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·Mv⟠From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:05 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Feb 12 20:01:05 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·Mv⟠From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:05 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:05 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Sun Feb 12 20:01:05 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:05 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Sun Feb 12 20:01:05 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Sun Feb 12 20:01:05 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·Mv⟠From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:05 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:05 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Feb 12 20:01:05 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Feb 12 20:01:05 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:05 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:05 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Sun Feb 12 20:01:05 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:05 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:05 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:05 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Feb 12 20:01:05 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:05 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:05 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Sun Feb 12 20:01:05 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Feb 13 08:16:53 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MvæŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 08:16:53 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Feb 13 08:16:54 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MvæŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 08:16:54 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 08:16:54 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Mon Feb 13 08:16:54 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 08:16:54 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Mon Feb 13 08:16:54 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Feb 13 08:16:55 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MvæŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 08:16:55 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 08:16:55 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Feb 13 08:16:55 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Feb 13 08:16:55 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 08:16:55 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 08:16:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Feb 13 08:16:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 08:16:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 08:16:56 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 08:16:56 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Feb 13 08:16:56 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 08:16:56 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 08:16:56 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Feb 13 08:16:57 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Feb 13 12:03:07 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MvêŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:07 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Feb 13 12:03:07 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MvêŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:07 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:07 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Mon Feb 13 12:03:07 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:07 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Mon Feb 13 12:03:07 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Feb 13 12:03:07 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MvêŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:07 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:07 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Feb 13 12:03:07 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Feb 13 12:03:07 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:07 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:07 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Feb 13 12:03:07 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:07 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:07 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:07 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Feb 13 12:03:07 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:07 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:08 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Feb 13 12:03:08 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Feb 13 16:01:24 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MvîŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:24 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Feb 13 16:01:24 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MvîŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:24 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:24 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Mon Feb 13 16:01:24 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:24 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Mon Feb 13 16:01:24 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Feb 13 16:01:24 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MvîŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:24 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:24 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Feb 13 16:01:24 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Feb 13 16:01:24 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:24 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:24 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Feb 13 16:01:24 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:24 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:24 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:24 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Feb 13 16:01:24 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:24 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:24 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Feb 13 16:01:24 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Feb 13 20:01:06 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MvòŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:06 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Feb 13 20:01:06 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MvòŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:06 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:06 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Mon Feb 13 20:01:06 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:06 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Mon Feb 13 20:01:07 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Mon Feb 13 20:01:07 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MvòŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:07 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:07 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Feb 13 20:01:07 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Feb 13 20:01:07 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:07 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:07 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Mon Feb 13 20:01:07 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:07 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:07 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:07 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Feb 13 20:01:07 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:07 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:07 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Mon Feb 13 20:01:07 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Feb 14 08:19:12 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MvöŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 08:19:12 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Feb 14 08:19:13 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MvöŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 08:19:13 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 08:19:13 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Tue Feb 14 08:19:13 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 08:19:13 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Tue Feb 14 08:19:13 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Feb 14 08:19:16 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MvöŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 08:19:16 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 08:19:16 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Feb 14 08:19:16 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Feb 14 08:19:16 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 08:19:16 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 08:19:16 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Feb 14 08:19:16 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 08:19:16 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 08:19:17 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 08:19:17 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Feb 14 08:19:17 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 08:19:17 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 08:19:17 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Feb 14 08:19:17 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Feb 14 12:03:22 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MwÒŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:22 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Feb 14 12:03:22 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MwÒŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:22 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:22 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Tue Feb 14 12:03:22 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:22 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Tue Feb 14 12:03:22 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Feb 14 12:03:22 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MwÒŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:22 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:22 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Feb 14 12:03:22 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Feb 14 12:03:22 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:22 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:22 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Feb 14 12:03:22 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:23 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:23 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:23 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Feb 14 12:03:23 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:23 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:23 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Feb 14 12:03:23 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Feb 14 16:01:32 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MwÖŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:32 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Feb 14 16:01:32 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MwÖŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:32 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:32 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Tue Feb 14 16:01:32 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:32 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Tue Feb 14 16:01:32 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Feb 14 16:01:32 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MwÖŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:32 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:32 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Feb 14 16:01:32 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Feb 14 16:01:32 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:32 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:32 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Feb 14 16:01:32 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:32 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:32 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:32 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Feb 14 16:01:32 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:32 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:32 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Feb 14 16:01:32 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Feb 14 20:01:13 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MwÚŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:13 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Feb 14 20:01:13 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MwÚŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:13 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:13 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Tue Feb 14 20:01:13 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:13 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Tue Feb 14 20:01:13 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Tue Feb 14 20:01:13 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MwÚŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:13 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:13 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Feb 14 20:01:13 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Feb 14 20:01:13 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:13 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:13 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Tue Feb 14 20:01:13 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:13 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:13 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:13 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Feb 14 20:01:13 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:13 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:13 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Tue Feb 14 20:01:13 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 15 08:27:27 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MwÞŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 08:27:28 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 15 08:27:31 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MwÞŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 08:27:31 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 08:27:31 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Wed Feb 15 08:27:31 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 08:27:31 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Wed Feb 15 08:27:32 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 15 08:27:35 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MwÞŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 08:27:36 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 08:27:36 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 15 08:27:36 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 15 08:27:37 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 08:27:37 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 08:27:37 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 15 08:27:37 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 08:27:38 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 08:27:38 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 08:27:38 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Feb 15 08:27:38 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 08:27:38 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 08:27:39 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Feb 15 08:27:39 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 15 12:05:24 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·Mw⟠From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 12:05:25 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 15 12:05:25 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·Mw⟠From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 12:05:25 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 12:05:25 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Wed Feb 15 12:05:25 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 12:05:25 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Wed Feb 15 12:05:25 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 15 12:05:25 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·Mw⟠From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 12:05:25 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 12:05:25 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 15 12:05:25 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 15 12:05:25 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 12:05:25 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 12:05:25 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 15 12:05:25 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 12:05:25 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 12:05:26 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 12:05:26 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Feb 15 12:05:26 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 12:05:26 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 12:05:26 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Feb 15 12:05:26 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 15 16:01:34 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MwæŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:34 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 15 16:01:34 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MwæŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:34 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:34 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Wed Feb 15 16:01:34 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:34 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Wed Feb 15 16:01:34 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 15 16:01:34 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MwæŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:34 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:35 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 15 16:01:35 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 15 16:01:35 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:35 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:35 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 15 16:01:35 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:35 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:35 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:35 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Feb 15 16:01:35 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:35 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:35 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Feb 15 16:01:35 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 15 19:28:02 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MwêŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:02 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 15 19:28:02 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MwêŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:02 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:02 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Wed Feb 15 19:28:02 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:03 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Wed Feb 15 19:28:03 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 15 19:28:03 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MwêŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:03 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:03 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 15 19:28:03 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 15 19:28:03 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:10 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:10 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 15 19:28:10 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:10 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:10 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:10 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Feb 15 19:28:10 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:10 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:10 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Feb 15 19:28:10 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 15 20:13:30 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MwîŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 20:13:33 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 15 20:13:36 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MwîŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 20:13:36 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 20:13:36 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Wed Feb 15 20:13:36 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 20:13:36 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Wed Feb 15 20:13:36 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Wed Feb 15 20:13:38 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MwîŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 20:13:38 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 20:13:38 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 15 20:13:38 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 15 20:13:38 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 20:13:38 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 20:13:38 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Wed Feb 15 20:13:38 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 20:13:38 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 20:13:38 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 20:13:38 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Feb 15 20:13:38 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 20:13:38 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 20:13:38 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Wed Feb 15 20:13:39 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Feb 16 08:46:10 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MwòŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 16 08:46:11 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Feb 16 08:46:13 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MwòŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 16 08:46:13 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 16 08:46:14 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Thu Feb 16 08:46:14 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 16 08:46:14 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Thu Feb 16 08:46:14 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Thu Feb 16 08:46:16 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MwòŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 16 08:46:16 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 16 08:46:16 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Feb 16 08:46:16 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Feb 16 08:46:16 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 16 08:46:16 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 16 08:46:16 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Thu Feb 16 08:46:16 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 16 08:46:16 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 16 08:46:17 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 16 08:46:17 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Feb 16 08:46:17 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 16 08:46:17 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 16 08:46:17 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Thu Feb 16 08:46:17 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > :::: From jhawley at eaglepress.com Tue Jan 6 10:09:28 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Mar 31 16:33:39 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëþœÛž5ãÚ¶Öœ†g§·MwöŸ From mal at egenix.com Tue Jan 6 16:15:48 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:39 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAD124.2020907@egenix.com> John Hawley, Jr wrote: > I have a Linux 7.2 machine and am attempting to install the > egenix-mx-base-2.0.5-py1.5_1.i386.rpm. Here is what is already > installed so far: > > Easysoft ODBC-ODBC bridge > > unixODBC 2.2.7 > > When I attempt to install the egenix-mx-base-2.0.5-py1.5_1.i386.rpm I > get a long list of conflicts. All have the following format: file > /usr/lib/python1.5/site-packages/mx/BeeBase/BeeDict.py from install of > egenix-mx-base-2.0.5-py1.5_1 conflicts with file from package mx-2.0.3-1 > > Then it continues down the list and appears that the entire package > conflicts w/ files from mx-2.0.3-1. That's because RedHat in its great wisdom has chosen to use a different RPM name than the one we started out with. I suppose that a bit of RPM magic will do the trick since 2.0.5 is backwards compatible to 2.0.3 and installs in the same location. > Any help on resolving this issue will be greatly appreciated. I also > tried to install the eginx-mx-commercial but it wanted the base package > installed first. A never ending cycle on linux. BTW I want to use > python scripts that are already in place to connect via odbc to a > Microsoft sql server database on a separate windows server. The python > scripts were originally written to connect to a SOLID database. > > > > John Hawley, Jr. > > Information Systems Administrator > > Eagle Press, Inc. > > 252.451.1825 ext 225 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From jhawley at eaglepress.com Tue Jan 6 10:57:48 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Mar 31 16:33:39 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMtëÿxõ§^÷ÏÚ¶Öœ†g§·MwöŸ From mal at egenix.com Tue Jan 6 18:07:00 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:39 2006 Subject: [egenix-users] Conflicts when installing egenix-mx-base-2.0.5-py1.5_1.i386.rpm In-Reply-To: References: Message-ID: <3FFAEB34.2000003@egenix.com> John Hawley, Jr wrote: > In reference to my previous thread. > > When installing the egenix-mx-base-2.0.5-py1.5_1.i386.rpm should I use: > > Rpm -nodeps or rpm -force to make the newer version of mx install w/out > conflicts from the older mx version. If so will this affect other items > (i.e. unixODBC, postgresql-python). Also I assume the mx-base-2.0.5 is > the newer version or my installed mx-2.0.3-1 and the older version will > be overwritten when installing mx-base2.0.5. AFAIK, the Redhat mx-2.0.3-1 is the same as the original egenix-mx-base-2.0.3 package. Version 2.0.5 is fully backwards compatible so you shouldn't run into any problems. The only thing to watch out for is that the version you are overwriting was built for the same Python version as used by the eGenix RPM. I know that Redhat switched to Python versions built with --enable-unicode=ucs4 some time ago which would then result in problems with the eGenix RPMs since these are built against Python built with the default UCS2 Unicode configuration setting. If that's the case for your installation, then you'd either have to build the package from source or ask Redhat for an updated package. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 8 19:47:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:39 2006 Subject: [egenix-users] Re: FW: Error Importing mx.ODBC.iODBC In-Reply-To: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> References: <004b01c3d612$62a239a0$660aa8c0@MARINASERVER> Message-ID: <3FFDA5C8.7030409@egenix.com> Gary Ebersole wrote: > Marc, > > Thanks for the earlier advice. I ran the setup install as recommended > below (base install worked fine) but gcc exited with an error that it > could not find '-liodbc' (see output below). The iODBC libraries are > installed in /usr/lib. Any suggestions? The command line looks OK. Perhaps there are permission problems ? You should have a file libiodbc.so in /usr/lib: -rw-r--r-- 1 root root 141852 Mar 17 2003 /usr/lib/libiodbc.a -rw-r--r-- 1 root root 712 Mar 17 2003 /usr/lib/libiodbc.la lrwxrwxrwx 1 root root 17 Aug 6 22:59 /usr/lib/libiodbc.so -> libiodbc.so.2.1.6 lrwxrwxrwx 1 root root 17 Aug 6 22:58 /usr/lib/libiodbc.so.2 -> libiodbc.so.2.1.6 -rwxr-xr-x 1 root root 126285 Mar 17 2003 /usr/lib/libiodbc.so.2.1.6 > Thanks again for your time and patience. > > Gary > > P.S. I have sent this to the list to preserve your initial response. I've checked the mailing list logs: they say you are not yet subscribed and thus ignore the messages (because we so much spam directed towards the list, we've disabled notices). > ----------------------------------------------- > $python setup.py install > running install > running build > running mx_autoconf > macros to define: [] > macros to undefine: [] > updated build_ext with autoconf setup > running build_ext > > building extension "mx.ODBC.iODBC.mxODBC" (required) > building 'mx.ODBC.iODBC.mxODBC' extension > creating build/temp.linux-i686-2.2 > creating build/temp.linux-i686-2.2/mx > creating build/temp.linux-i686-2.2/mx/ODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC > creating build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxODBC.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC > -fPIC -DiODBC -Imx/ODBC/iODBC -I/usr/local/iODBC/include > -I/usr/include/python2.2 -I/usr/local/include -I/usr/include -c > mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > gcc -shared build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxODBC.o > build/temp.linux-i686-2.2/mx/ODBC/iODBC/mxODBC/mxSQLCodes.o > -L/usr/local/iODBC/lib -L/usr/local/lib -L/usr/lib -liodbc -o > build/lib.linux-i686-2.2/mx/ODBC/iODBC/mxODBC.so > /usr/bin/ld: cannot find -liodbc > collect2: ld returned 1 exit status > error: command 'gcc' failed with exit status 1 > > > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@egenix.com] > Sent: Thursday, January 08, 2004 8:43 AM > To: garyeb@pacbell.net > Subject: Re: FW: Error Importing mx.ODBC.iODBC > > > Gary Ebersole wrote: > >>Marc, >> >>My apologies for forwarding this to you directly but I had not heard >>back with a confirmation email on joining the egenix-users. I sent >>this message to the list but I'm not certain if it was posted. > > > It has not made it to the list; not sure why -- there's no notice of it > being held by Mailman. > > >>Thanks for any help you can provide. >> >>Gary >> >>-----Original Message----- >>From: Gary Ebersole [mailto:garyeb@pacbell.net] >>Sent: Thursday, January 08, 2004 8:07 AM >>To: egenix-users@lists.egenix.com >>Subject: Error Importing mx.ODBC.iODBC >> >> >>I'm a Python newbie struggling with trying to install the mxODBC >>package from Egenix in RH Linux 9 (kernel (2.4.20). Per the dialogue >>below, I used the mxBase and commercial binary RPMs for the default >>Python 2.2 installed by RH into the /usr directory. I also built a 2.3 > > >>version of Python, installed it in /usr/local and then installed the >>appropriate Egenix packages. The iODBC package had been successfully >>installed earlier (the IODBC driver manager admin tool was able to >>locate and install an ODBC driver). However, I was forced to use >>'--nodeps' to override the following error message even though these >>libraries were in >>/usr/lib: >> >>error: Failed dependencies: >> libiodbc.so.2 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> libodbc.so.1 is needed by egenix-mx-commercial-2.0.6-py2.2_1 >> >>Running both Python 2.2 and 2.3 generated the following error when >>trying to import mx.ODBC.iODBC: >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString > > > The problem is that Redhat builds Python using UCS4 Unicode, while we > ship RPMs that use Python's default setting UCS2. > > You will have to build both packages from source: > > 1. untar the source archive > 2. cd to the package dir > 3. python2.2 setup.py install > > That's it. > > >>Any ideas? It's probably painfully obvious to experienced Python and >>Linux users but I'm at a loss. I'd hate to revert to learning Perl >>since Python is ideal for someone with my requirements. > > > > >>Thanks! >> >>Gary >> >>USING PYTHON 2.2 INSTALLED IN /USR BY REDHAT >>-------------------------------------------- >>Egenix Packages installed: >> egenix-mx-base-2.0.5-py2.2_1 >> egenix-mx-commercial-2.0.6-py2.2_1 >> >>$ /usr/bin/python >>Python 2.2.2 (#1, Feb 24 2003, 19:13:11) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', >>'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages', >>'/usr/lib/python2.2/site-packages/gtk-2.0'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.2/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >> from mxODBC import * >>ImportError: /usr/lib/python2.2/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> >> >>USING PYTHON 2.3 INSTALLED IN /USR/LOCAL >>---------------------------------------- >>Egenix packages installed: >> egenix-mx-base-2.0.5-py2.3_1 >> egenix-mx-commercial-2.0.6-py2.3_1 >> >>$ /usr/local/bin/python >>Python 2.3.3 (#1, Jan 7 2004, 14:09:01) >>[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 >>Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>>import sys >>>>>sys.path >> >>['', '/usr/local/lib/python23.zip', '/usr/local/lib/python2.3', >>'/usr/local/lib/python2.3/plat-linux2', >>'/usr/local/lib/python2.3/lib-tk', >>'/usr/local/lib/python2.3/lib-dynload', >>'/usr/local/lib/python2.3/site-packages'] >> >> >>>>>import mx >>>>>import mx.DateTime >>>>>import mx.ODBC >>>>>import mx.ODBC.iODBC >> >>Traceback (most recent call last): >> File "", line 1, in ? >> File "/usr/lib/python2.3/site-packages/mx/ODBC/iODBC/__init__.py", >>line 8, in ? >>ImportError: >>/usr/local/lib/python2.3/site-packages/mx/ODBC/iODBC/mxODBC.so: >>undefined symbol: PyUnicodeUCS2_AsEncodedString >> > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From CHALUB at fgv.br Mon Jan 12 11:33:14 2004 From: CHALUB at fgv.br (Fabricio Chalub) Date: Fri Mar 31 16:33:39 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? Message-ID: Hello, Does anyone observe this behavior on mxODBC? I get a mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) when running the simple example below. The values are actually inserted on the database, but mxODBC dies with that error. I'm using FreeTDS 0.62rc3 (current), iODBC (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting to SQL Server 2000. If I do the placeholder substitution directly, ie, do something like INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') it works nicely. Any ideas to make this work with the placeholders cleanly? --- import mx.ODBC.iODBC cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" c2 = cto.cursor() c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) Thanks, Fabricio From mal at egenix.com Mon Jan 12 14:58:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:39 2006 Subject: [egenix-users] 'Invalid cursor state' when using placeholders? In-Reply-To: References: Message-ID: <4002A804.9070308@egenix.com> Fabricio Chalub wrote: > Hello, > > Does anyone observe this behavior on mxODBC? > > I get a > > mxODBC.InternalError: ('24000', 0, '[FreeTDS][SQL Server]Invalid cursor state', 2363) > > when running the simple example below. The values are > actually inserted on the database, but mxODBC dies with > that error. I'm using FreeTDS 0.62rc3 (current), iODBC > (3.51.1), unixODBC (2.2.7) and mxODBC (2.0.6) connecting > to SQL Server 2000. This looks like a bug in FreeTDS: mxODBC is trying to read the number of rows in the result set. Since there is no result set, the ODBC should return 0 (like all other drivers do). Instead, FreeTDS reports an error. > If I do the placeholder substitution directly, ie, do > something like > > INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES ('C',1,'a','b','c','d') > > it works nicely. Any ideas to make this work with > the placeholders cleanly? Not cleanly, but in this case, you can safely ignore the false error from FreeTDS. I'd suggest sending them a bug report. > --- > > import mx.ODBC.iODBC > cto = mx.ODBC.iODBC.DriverConnect ("DSN=sqlserver;UID=YYY;PWD=XXX") > areaI = "INSERT INTO some_table (c1,c2,c3,c4,c5,c6) VALUES (?,?,?,?,?,?)" > c2 = cto.cursor() > c2.execute(areaI, ('C', 1, 'T1', 'T2', 'T3', 'T4')) > > Thanks, > Fabricio > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From walgraffe at dupuis.com Mon Jan 12 15:52:29 2004 From: walgraffe at dupuis.com (=?iso-8859-1?Q?S=E9bastien_Walgraffe?=) Date: Fri Mar 31 16:33:39 2006 Subject: [egenix-users] Problem when accessing connection information. Message-ID: Hello! I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python 2.1.3, win32 And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content of the extract in my product directory, replacing previous files of MXODBC Zope DA 1.0.6) But now, it s impossible to access information when I click on the connection object... I get the following error : Exception Type KeyError Exception Value connection_info Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec KeyError: connection_info It is like if some attribute was lost during the update... Is there something I can do to correct this error? I can t change parameters or close connection once created, and that s really annoying. Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the product to re-install it properly. Thanks for your help! Sebastien Walgraffe From jhawley at eaglepress.com Mon Jan 12 10:06:06 2004 From: jhawley at eaglepress.com (John Hawley, Jr) Date: Fri Mar 31 16:33:40 2006 Subject: [egenix-users] file not in gzip format Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zz-jö¢•¦åy<©z)šïà‰ô¢Íí}õ¼­zÀޱȦj´ÓX"}Jåþf¢–f§j·!Š÷¬ýèž,n±êìý«miÈfz{lÿm4ãMuÛö½çÎ|kÏÚ¶Öœ†g§·MwöŸ From mal at egenix.com Mon Jan 12 16:18:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:40 2006 Subject: [egenix-users] Problem when accessing connection information. In-Reply-To: References: Message-ID: <4002BAC7.5000705@egenix.com> S?bastien Walgraffe wrote: > Hello! > > I m working with Zope 2.6.1 (binary release, python 2.1, win32-x86), python > 2.1.3, win32 > > And I installed latest version of mxODBC Zope DA 1.0.7 (I copied the content > of the extract in my product directory, replacing previous files of MXODBC > Zope DA 1.0.6) > > But now, it s impossible to access information when I click on the > connection object... I get the following error : > > Exception Type KeyError > Exception Value connection_info > Traceback (innermost last): > * Module ZPublisher.Publish, line 98, in publish > * Module ZPublisher.mapply, line 88, in mapply > * Module ZPublisher.Publish, line 39, in call_object > * Module Shared.DC.Scripts.Bindings, line 252, in __call__ > * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > * Module App.special_dtml, line 174, in _exec > KeyError: connection_info > > > It is like if some attribute was lost during the update... > Is there something I can do to correct this error? > > I can t change parameters or close connection once created, and that s > really annoying. > > Maybe I wrongly installed mxODBC Zope DA and I should remove entirely the > product to re-install it properly. When updating the product, you should always copy the license files from lib/python/mx/ODBC to a safe place and then remove the directories lib/python/mx and lib/python/Products/mxODBCZopeDA *before* installing the new version of the product. This is needed to make sure that no temporary files or byte code files from a previous installation are left over and mix in with the new files. After you have uninstalled the product that way, unzip the new archive and reinstall the license files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Mon Jan 12 16:19:38 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:40 2006 Subject: [egenix-users] file not in gzip format In-Reply-To: References: Message-ID: <4002BB0A.6060605@egenix.com> John Hawley, Jr wrote: > I have downloaded the files: > > Egenix-mx-base-2.0.2.tat.gz and egenix-mx-commercial-2.0.6.tar.gz > > When I try to unzip using gunzip or gzip -d I get the message: file not > in gzip format. I am using a Redhat linux 7.2 to unzip. Any > suggestions? I need these files as the rpm are not working. Your browser probably did the gunzip for you when you downloaded the files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Wed Jan 14 17:45:14 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Mar 31 16:33:40 2006 Subject: [egenix-users] RelativeDateTime Message-ID: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Hello, I'm working on an application that make an intensive uses of RelativeDateTime. I have read the manual and have seen this tragic note : "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. So my question is : Is there any plan to fix that ? If any, when ? If not, as a python developper, how can I contribute and add the missing features ? Or can egenix consulting services do that ? What about the price ? Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From francois.girault at clarisys.fr Thu Jan 15 09:55:29 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Mar 31 16:33:40 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074139711.26201.24.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> Message-ID: <20040115095529.157d73eb.francois.girault@clarisys.fr> > Hmm, what you may want to do is write a series of unit tests that > demonstrate the behavior you expect. For instance, what do you expect > this to be: > > Date(1999, 1, 31) + RelativeDateTime(months=+1) > > Or maybe you want to say: > > Date(1999, 1, 31) + RelativeDateTime(absoluteMonths=+1) > > where absoluteMonths is always 30? > Great idea. I'll do unit tests to show what I expect > You see--it's not at all obvious (at least to me), what you expect. A > series of tests would be half the battle. > I agree that it's not at all obvious (or I won't post there). I omitted to tell about the full context of my need : it's related to postgresql database and the module pypgsql. I've made a patch to pypgsql project (pypgsql.sf.net) in order to map postgres interval type to RelativeDateTime instead of DateTimeDelta because several calculation went wrong. I've posted this patch to pypgsql user mailing list, and it seems that I'm not the only one that need correct calculation with interval of time. Karsten Hilbert from GnuMed project said : "I support inclusion of the patch. Had the same problem when calculating due/overdue vaccinations for GnuMed." So the behavior we expect is the same than postgresql with interval type. IMHO, postgresql (ie SQL99 interval type) has a very logical point of view about this non obvious problem. What do you think about that ? I'm ok to write unit test about that if needed, tell me if it is necessary. Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Thu Jan 15 11:50:55 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:40 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115095529.157d73eb.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> Message-ID: <4006708F.4060707@egenix.com> Francois Girault wrote: > So the behavior we expect is the same than postgresql with interval > type. IMHO, postgresql (ie SQL99 interval type) has a very logical point > of view about this non obvious problem. What do you think about that ? Do you have a reference for this ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Jan 15 12:02:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:40 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040114174514.02ebaa19.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> Message-ID: <4006733B.8040306@egenix.com> Francois Girault wrote: > Hello, > > I'm working on an application that make an intensive uses of RelativeDateTime. > > I have read the manual and have seen this tragic note : > > "Note that dates like Date(1999,1,30) + RelativeDateTime(months=+1) are not supported. The package currently interprets these constructions as Date(1999,2,1) + 30, thus giving the 1999-03-02 which may not be what you'd expect." > > well, it's no what i expect :/, especially while manipulating medical related data that *must* be perfectly correct... This is an imperative need for the project I'm working on. Question is: what is perfectly correct ? I think that the only true solution would be to raise an exception, but I'm open to more useful options. (I'm not a particular fan of the current situation either.) > So my question is : > > Is there any plan to fix that ? If any, when ? > > If not, as a python developper, how can I contribute and add the missing features ? You can contribute a patch, but you would have place that patch into the public domain. > Or can egenix consulting services do that ? What about the price ? eGenix will implement changes at customer request to build customized versions. Whether or not these changes will go into the open source packages is a question of whether the changes break compatibility or not. The Unicode support in mxTextTools 2.1 is an example of where we have integrated the changes requested by a customer back into the open source version. > Another request about RelativeDateTime : adding the __cmp__ method. I think it's easy and useful to add. I can do that if nobody want to (or need to). Are patches welcome to mxBase ? Yes, but please put them into the public domain. We don't want to start long discussions about who own the IP, licenses, etc. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From francois.girault at clarisys.fr Thu Jan 15 17:40:06 2004 From: francois.girault at clarisys.fr (Francois Girault) Date: Fri Mar 31 16:33:40 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <4006708F.4060707@egenix.com> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> Message-ID: <20040115174006.738ee5a0.francois.girault@clarisys.fr> On Thu, 15 Jan 2004 11:50:55 +0100 M.-A. Lemburg wrote: > Francois Girault wrote: > > So the behavior we expect is the same than postgresql with interval > > type. IMHO, postgresql (ie SQL99 interval type) has a very logical > > point of view about this non obvious problem. What do you think > > about that ? > > Do you have a reference for this ? > This directory contains many docs about SQL99 : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ But I haven't found a fully explained date arithmetic. In this document : http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf a chapter about interval says on page 29 : "Arithmetic operations involving values of type datetime or interval obey the natural rules associated with dates and times and yield valid datetime or interval results according to the Gregorian calendar." "natural rules" are *very* ambigious, but playing with postgres tell more about that : => SELECT date('2002-01-30') + "interval"('1 mon'); ?column? --------------------- 2002-02-28 00:00:00 (1 row) For date from january, 28th to january, 31th adding one month result in the last day of february. From a math point of view, it seems wrong, but thinking more about make me consider it 'natural' Regards, Fran?ois Girault Clarisys Informatique - http://www.clarisys.fr From mal at egenix.com Mon Jan 19 13:01:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:40 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <20040115174006.738ee5a0.francois.girault@clarisys.fr> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> Message-ID: <400BC718.5040408@egenix.com> Francois Girault wrote: > On Thu, 15 Jan 2004 11:50:55 +0100 > M.-A. Lemburg wrote: > > >>Francois Girault wrote: >> >>>So the behavior we expect is the same than postgresql with interval >>>type. IMHO, postgresql (ie SQL99 interval type) has a very logical >>>point of view about this non obvious problem. What do you think >>>about that ? >> >>Do you have a reference for this ? >> > > This directory contains many docs about SQL99 : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ > > But I haven't found a fully explained date arithmetic. > > In this document : > > http://trinetra.ncb.ernet.in/education/modules/dbms/SQL99/ansi-iso-9075-2-1999.pdf > > a chapter about interval says on page 29 : "Arithmetic > operations involving values of type datetime or interval obey the > natural rules associated with dates and times and yield valid datetime > or interval results according to the Gregorian calendar." > > "natural rules" are *very* ambigious, but playing with postgres tell > more about that : > > => SELECT date('2002-01-30') + "interval"('1 mon'); > ?column? > --------------------- > 2002-02-28 00:00:00 > (1 row) > > For date from january, 28th to january, 31th adding one month result in > the last day of february. From a math point of view, it seems wrong, but > thinking more about make me consider it 'natural' The problem with this approach is obvious, e.g. what would the outcome of the following variations be: Date(2004,1,31) + RelativeDateTime(months=+1) Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) Date(2004,1,31) + RelativeDateTime(months=+3) BTW, the stragety chosen in mxDateTime's implementation for RelativeDateTime matches that of MS Excel VBA, see e.g. http://www.cpearson.com/excel/datearith.htm (Only by accident, I must say :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 11:53:13 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:40 2006 Subject: [egenix-users] RelativeDateTime In-Reply-To: <1074521580.5354.33.camel@dev.internal> References: <20040114174514.02ebaa19.francois.girault@clarisys.fr> <1074139711.26201.24.camel@dev.internal> <20040115095529.157d73eb.francois.girault@clarisys.fr> <4006708F.4060707@egenix.com> <20040115174006.738ee5a0.francois.girault@clarisys.fr> <400BC718.5040408@egenix.com> <1074521580.5354.33.camel@dev.internal> Message-ID: <4010FD19.9090208@egenix.com> Mark McEahern wrote: > [Francois Girault] > >>>"natural rules" are *very* ambigious, but playing with postgres tell >>>more about that : >>> >>>=> SELECT date('2002-01-30') + "interval"('1 mon'); >>> ?column? >>>--------------------- >>> 2002-02-28 00:00:00 >>>(1 row) >>> >>>For date from january, 28th to january, 31th adding one month result in >>>the last day of february. From a math point of view, it seems wrong, but >>>thinking more about make me consider it 'natural' > > > [M.-A. Lemburg] > >>The problem with this approach is obvious, e.g. what would >>the outcome of the following variations be: >> >>Date(2004,1,31) + RelativeDateTime(months=+1) >>Date(2004,1,31) + RelativeDateTime(months=+2) - RelativeDateTime(months=-2) >>Date(2004,1,31) + RelativeDateTime(months=+3) > > > What about using a different interval--e.g., instead of "months", > "weirdmonths". When adding/subtracting "weirdmonths", you'd do the math > on the month part and adjust the day value accordingly in the case of > overflow (i.e., the new month doesn't have the same number of days) or > underflow (i.e., you were on the last day of the original month, but the > new month has more days--should you still be on the last day?). Hmm, I > wonder what Postgresql does for the equivalent of this: > > Date(2004, 4, 30) + RelativeDateTime(weirdmonths=-1) > > You'd think the answer would be Date(2004, 3, 31). However: > > courier=> SELECT date('2004-04-30') - "interval"('1 mon'); > ?column? > --------------------- > 2004-03-30 00:00:00 > (1 row) > > So, the day adjustment only seems to happen in the case of overflow. The idea of using a new parameter is a good one; I think "intmonths" would be a suitable name. The semantics being the same as for month with the exception of the overflow case. intmonths would truncate the day to the last day of the month in case of an overflow. The results for the above would be: Date(2004,1,31) + RelativeDateTime(intmonths=+1) == Date(2004,2,29) Date(2004,1,31) + RelativeDateTime(intmonths=+1) - RelativeDateTime(intmonths=-1) == Date(2004,1,29) Date(2004,1,31) + RelativeDateTime(intmonths=+2) - RelativeDateTime(intmonths=-2) == Date(2004,1,31) Date(2004,1,31) + RelativeDateTime(intmonths=+3) == Date(2004,4,30) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Fri Jan 23 16:51:19 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:40 2006 Subject: [egenix-users] ANN: eGenix mxODBC Zope Database Adapter 1.0.8 Message-ID: <401142F7.1070602@egenix.com> ________________________________________________________________________ ANNOUNCEMENT EGENIX.COM mxODBC Zope Database Adapter Version 1.0.8 Available for Zope 2.3 through 2.7 on Windows, Linux, Solaris and FreeBSD ________________________________________________________________________ INTRODUCTION The eGenix mxODBC Zope Database Adapter (Zope DA) allows you to easily connect your Zope installation to just about any database backend on the market today, giving you the reliability of the commercially supported eGenix.com product mxODBC and the flexibility of the ODBC standard as middle-tier architecture. Unlike Zope's ZODBC Zope DA, the mxODBC Zope DA works on Windows XP/NT/2000/98, Linux, Solaris and FreeBSD using the same interface on all platforms. The mxODBC Zope DA implements high performance thread-safe connection pooling and multiple physical connects per logical Zope connection. You can safely run Z SQL Methods in parallel, achieving a much better throughput than ZODBC Zope DA or similar Zope database adapters under heavy load. This makes it ideal for deployment in ZEO Clusters and Zope hosting environments where stability and high performance are a top priority. ________________________________________________________________________ FEATURES * Zope Level 3 Database Adapter: the mxODBC Zope DA is fully multi-threaded and can handle multiple connections to multiple databases. * Fully compatible to Z SQL Methods. * Drop-in compatible to the ZODBC DA: the mxODBC Zope DA provides the same interfaces as Zope's ZODBC DA to allow a smooth upgrade path from this simplistic adapater to the high performance mxODBC Zope DA. * Fully compatible to the Znolk SQL Wizard Product and other similar products relying on the common database schema access methods .tables() and .columns(). * Connection Pooling: physical database connections are pooled and kept open, to reduce the connection overhead to a minimum. This is especially important for high latency database connections and ones like Oracle which take a considerable amount of time to setup * Parallel Execution of Queries on a single logical connection: the mxODBC Zope DA can manage any number of physical connections on a single logical connection. This enables running truly parallel Z SQL Method queries -- a feature not available in other Zope DAs. * Robust Mode of Operation: connections which have timed out or go away due to network problems are automatically reconnected. * Cross-platform Connection Objects: The Zope DA will automatically choose the right platform specific ODBC manager for you. * Per Connection Adjustable ODBC Interface: mxODBC comes with many different subpackages to choose from on Unix. The Zope DA allows you to select these subpackages on a per-connection basis. * Per Connection Error Handling: you can tell each connection whether it should report ODBC warnings or not; furthermore all warnings and errors are made available as list .messages on the DatabaseConnection object. * Transaction safe automatic reconnect: when the DA finds that a connection has timed out, it automatically tries a reconnect and replays the transaction on the connection (unlike other DAs which break the transaction scheme by doing a reconnect without replay). * Built-in Schema Cache: this results in improved performance under heavy load. * Database Schema Access: all ODBC catalog methods are made available for much better database schema inquiry. The catalog methods allow building generic database interrogation or manipulation tools and facilitates writing database independent Zope products. * Lazy Connect: the mxODBC Zope DA only connects to the database backends when a connection is actually requested. This results in a better use of resources compared to other Zope DAs. ________________________________________________________________________ NEWS Version 1.0.8 includes the following changes and enhancements: * Zope 2.7.0 and Python 2.3 are fully supported on all platforms: Windows, Linux, Solaris and FreeBSD. * You can let the mxODBC Zope DA return empty strings instead of None for SQL NULL values. This should simplify porting existing applications to the mxODBC Zope DA. * The included mxODBC 2.1 provides full Unicode support if accessed directly. Using e.g. the EasySoft ODBC-ODBC bridge this allows you to connect to any remote Unicode aware ODBC backend from any of the supported platforms. In short: mxODBC Zope DA is continuing to become the number one solution for integrating relational databases with Zope applications. ________________________________________________________________________ UPGRADING If you have already bought mxODBC Zope DA licenses, you can use these license for the updated version as well. There is no need to buy new licenses. The same is true for evaluation license users. ________________________________________________________________________ MORE INFORMATION For more information on the mxODBC Zope DA, licensing and download instructions, please visit our web-site: http://zope.egenix.com/ You can buy mxODBC Zope DA licenses online from the eGenix.com shop at: http://shop.egenix.com/ ________________________________________________________________________ Thank you, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 23 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 04:20:00 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Mar 31 16:33:40 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? Message-ID: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Hello, I am new to using eGenix and I was trying to run an install on OS X Panther [10.3], which I recently upgraded to. I downloaded the eGenix base install and ran "python setup.py install". I had to modify mxSetup.py to include the following location for header files: INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, 'include'\ ), '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Once this was done, the install completed successfully however, I cannot import certain packages: """ [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Queue Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Stack Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.TextTools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.BeeBase >>> import mx.Tools Fatal Python error: Interpreter not initialized (version mismatch?) Abort [James-Richardss-Computer:~] hanuman% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mx.Misc >>> """ So, I can import mx.Misc and mx.BeeBase with no problems but the other packages return 'Interpreter not initialized' errors. Does anyone have any idea what might cause this? Thanks, James From mal at egenix.com Wed Jan 28 11:09:31 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:40 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178A5B.5010809@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) > > Once this was done, the install completed successfully however, I > cannot import certain packages: Have you built the extensions using the same compiler as Python itself ? The error you get is typical on other platforms (we don't support OS X), which load to different Python DLLs and then find that one of them is not initialized. > """ > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Queue > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Stack > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.TextTools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.BeeBase > >>> import mx.Tools > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort > [James-Richardss-Computer:~] hanuman% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import mx.Misc > >>> > """ > > So, I can import mx.Misc and mx.BeeBase with no problems but the other > packages return 'Interpreter not initialized' errors. > > Does anyone have any idea what might cause this? > > Thanks, > > James > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Wed Jan 28 11:18:15 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:40 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> Message-ID: <40178C67.7010103@egenix.com> heiho1@mac.com wrote: > Hello, > > I am new to using eGenix and I was trying to run an install on OS X > Panther [10.3], which I recently upgraded to. I downloaded the eGenix > base install and > ran "python setup.py install". I had to modify mxSetup.py to include > the following location for header files: > > INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, > 'include'\ > ), > '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ ']) Hmm, I wonder why you had to tweak the INCLPATH since that's only used for finding include files of external libraries. distutils should already have added such a dir to the standard search path. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From heiho1 at mac.com Wed Jan 28 09:10:51 2004 From: heiho1 at mac.com (heiho1@mac.com) Date: Fri Mar 31 16:33:40 2006 Subject: [egenix-users] Interpreter not initialized (version mismatch?) installing egenix mxBase? In-Reply-To: <40178C67.7010103@egenix.com> References: <2589FA94-5173-11D8-BEF2-000A957D364E@mac.com> <40178C67.7010103@egenix.com> Message-ID: It's possible that this problem is occurring because I updated OS X without applying the Developer CD update... I had to tweak the INCLPATH because the header files were located beneath /Library rather than /System [where libs, pyc, etc] files were located. I just upgraded so I'm not too sure why the paths are different :). I'll look some more. Thanks, James >> Hello, >> I am new to using eGenix and I was trying to run an install on OS X >> Panther [10.3], which I recently upgraded to. I downloaded the >> eGenix base install and >> ran "python setup.py install". I had to modify mxSetup.py to include >> the following location for header files: >> INCLPATH = build_path(['/usr/local/include', os.path.join(sys.prefix, >> 'include'\ >> ), >> '/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/ >> ']) > > Hmm, I wonder why you had to tweak the INCLPATH since that's only > used for finding include files of external libraries. > > distutils should already have added such a dir to the standard > search path. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 27 > 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > _______________________________________________________________________ > _ > 2004-01-23: Released mxODBC.Zope.DA 1.0.8 > http://zope.egenix.com/ > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > ::::